MDEV-39538: Different costs when same range is read twice#5128
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a tracking mechanism for multi-range read (MRR) calls using a counter (call_number) to resolve issues where different costs are calculated when the same range is read multiple times. Feedback on the changes highlights a critical null-pointer dereference risk in sql/opt_context_store_replay.cc where call_number is assigned before verifying if range_ctx is null. Additionally, an optimization is suggested to defer sequence iterator initialization until after verifying the call_number matches the current counter.
bsrikanth-mariadb
force-pushed
the
13.1-MDEV-39538-different-cost-when-same-range-is-read-twice
branch
2 times, most recently
from
c2c3b5e to
9618d55
Compare
bsrikanth-mariadb
force-pushed
the
13.1-MDEV-39538-different-cost-when-same-range-is-read-twice
branch
5 times, most recently
from
302bd8f to
8be108b
Compare
When same range is used as a filter, once in the outer query block, and the second inside a sub query such as: - select * from t1 where year(a) = 2010 and c < (select count(*) from t1 where year(a) = 2010); The Optimizer Context had two records for multi_range_read_info_const() call, but had different cost vector members. The cause is that the first table considered index-only scan on the range, while the second considered non-index only scan. However, when replaying the context, the same range got matched twice, and the costs corresponding to that got returned twice. Hence the costs in the explain plan output differed as well. Solution ======== Include a new field called "call_number", while recording range contexts into the overall context. This way, we could even match the call_number and return the appropriate cost during replay.
bsrikanth-mariadb
force-pushed
the
13.1-MDEV-39538-different-cost-when-same-range-is-read-twice
branch
from
8be108b to
3efa973
Compare
|
A note: we could have also saved 'index-only' as a parameter of the call. |
2 participants
When same range is used as a filter, once in the outer query block, and the second inside a sub query such as: -
select * from t1
where year(a) = 2010 and c < (select count(*) from t1 where year(a) = 2010);
The Optimizer Context had two records for multi_range_read_info_const() call, but had different cost vector members.
The cause is that the first table considered index-only scan on the range, while the second considered non-index only scan.
However, when replaying the context, the same range got matched twice, and the costs corresponding to that got returned twice. Hence the costs in the explain plan output differed as well.
Solution
Include a new field called "call_number", while recording range contexts into the overall context. This way, we could even match the call_number and return the appropriate cost during replay.